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Modern service-oriented systems are often built by reusing, and composing together, existing ser¬ 
vices distributed over the Internet. Service choreography is a possible form of service composition 
whose goal is to specify the interactions among participant services from a global perspective. In this 
paper, we formalize a method for the distributed and automated enforcement of service choreogra¬ 
phies, and prove its correctness with respect to the realization of the specified choreography. The 
formalized method is implemented as part of a model-based tool chain released to support the devel¬ 
opment of choreography-based systems within the EU CHOReOS project. We illustrate our method 
at work on a distributed social proximity network scenario. 


1 Introduction 


The future trend in service-oriented development is to build systems by reusing, and composing together, 
existing services distributed over the Internet. 

Service choreography is a form of service composition whose goal is to specify message exchanges 
among multiple partner services, called participants, from a global perspective. When building a service- 
based system, a possible engineering approach is to compose services in a distributed way by considering 
this global specification. To this extent, the following two problems are usually considered: (a) realiz¬ 
ability check - checks whether the choreography can be realized by implementing each participant so that 
it conforms to the choreography role that specifies its “expected” behaviour; and (b) conformance check 
- checks whether the global interaction of a set of services satisfies the choreography. In the literature 
many approaches have been proposed to address these problems, e.g., lHT’.l37 . 35.71[Hll. However, when 
the goal is to actually realize a service choreography by reusing third-party services, hence going beyond 
just checking its effectiveness, a further problem worth to be considered concerns automated choreog¬ 
raphy enforcement. That is, how to coordinate the interactions among participant services in order to 
fit the choreography specification. This requires to distribute and enforce, among the participants, the 
global coordination logic extracted from the choreography specification. The general problem here is 
that, although services may have been discovered or registered as suitable participants, their composite 
interaction may prevent the choreography realization if left uncontrolled (or wrongly coordinated). 

B PMN2Q Choreography Diagrams represent a de facto standard in the current practice of choreog¬ 
raphy specification and design. Within the CHOReOS EU projecQ the work presented in this paper 
is part of, we implemented a model-based transformatior0 to synthesize, out of a BPMN2 choreogra¬ 
phy diagram, an intermediate state-based model called Choreography explicit-Flow Model (CeFM). The 
latter is a choreography model that, conforming to the BPMN2 standard specification, makes explicit 


'http://www.omg.org/spec/BPMN/2.0 
2 http://www.choreos.eu 

3 See documentation available at choreos . disim. univaq. it for details. 
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coordination-related information that in BPMN2 is implicit. This allows to statically infer the informa¬ 
tion needed for enabling distributed coordination that, otherwise, should be calculated at run time for 
each choreography instance and for each execution of it. For instance, the CeFM model specifies the 
source and target state from which a task is initiated and terminated, the corresponding transition and 
enabling condition. 


Choreography explicit-Flow Model 
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Figure 1: Overview of the choreography enforcement method 


Contribution of the paper - In this paper, we formalize a choreography enforcement method based on 
distributed coordination of the participants from outside. Figure [T] shows an overview of our method as 
organized into three steps. Out of a CeFM C, our method automatically derives a set of what we call 
Coordination Delegates (CDs). In particular, the coordination logic modeled by C is distributed into a 
set of Coordination Models (CMs), one for each CD (step 1 in the figure). The CDs exploit the CMs 
in order to coordinate the interaction of the participants in a way that the resulting collaboration real¬ 
izes the choreography specified by C (step 2 in the figure). The derived CDs are interposed (only when 
strictly needed) among the participants according to the CHOReOS architectural style (3| [14] (step 3 in 
the figure). To give an intuition, Figure [l]uses a box/arrow (i.e., component/connector) notation to show 
a sample architecture instance conforming to the CFlOReOS style (see the bottom-most diagram in the 
right-hand side of the figure). Within CFlOReOS, our method refers to a service registry to discover ser¬ 
vices that are suitable to play the roles of the choreography. The registry contains services published by 
providers that have identified business opportunities in the domain of interest. The registry also contains 
the registration of the end users interested in exploiting the choreography through client applications. 

CDs perform pure business-level coordination by proxifying the service interaction, and mediate it 
by exchanging the coordination information contained in their own CMs, in a fully distributed way. In 
this way, CDs prevent possible undesired interactions. The latter are those interactions that do not belong 
to the set of interactions allowed by C and can happen when the services collaborate in an uncontrolled 
way. We formalize the notions of CeFM and CM, and show how to decompose a CeFM into a set of 
CMs. Furthermore, we describe the distributed coordination algorithm that is implemented by the CDs 
to realize the coordination logic. 

The overall enforcement approach has been implemented as a set of REST services, and a graphical 
Eclipse plugin that invokes them has been releasecQ A tool demo screencast is also available. 


4 choreos.disim.univaq.it and www.ow2.org/view/Future_Internet 
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Advance with respect to our previous work - The work described in this paper represents an ad¬ 
vance with respect to our previous work in In fact, although the synthesis process described there 
treats most of the BPMN2 constructs, it considers a simplified version of their actual semantics. For 
instance, the selection of conditional branches is simply abstracted as a non-deterministic choice, regard¬ 
less the run-time evaluation of their enabling conditions. Analogously, parallel flows are enforced by 
non-deterministically choosing one of their linearizations obtained through interleaving, hence loosing 
the actual parallelism degree. To overcome these limitations, in this paper, we formalize the CeFM model 
that, being more expressive than the choreography model adopted in 0, preserves the actual semantics 
of the BPMN2 constructs. Relying on the CeFM model has led us to define a novel and more effective 
distributed coordination algorithm. As a further advance with respect to 0, we also prove correctness 
of the algorithm with respect to preventing undesired interactions. In particular, the proof gives a rigor¬ 
ous char acterization of the notion of undesired interaction that in 0 has been informally heated hence 
making it difficult to effectively assess our method. 

Main focus of the paper - It is worth to mention that the coordination logic performed by the CDs is 
service-independent since it is based on the expected behaviour of the participants as specified by C, 
rather than on the actual one as obtained after discovery. Within CHOReOS, this is done to consistently 
realize separation of concerns. That is, to separate pure coordination issues (i.e., undesired interactions) 
from adaptation ones (e.g., syntactic mismatches at the service interface level). The latter can arise 
whenever a service discovered as a participant does not exactly match the role to be played. Adaptation 
issues, as well as discovery ones, are out of scope for this paper and we refer to I4ll23l for details about 
their treatment within CHOReOS. 

Structure of the paper - Section [2] introduces a distributed social proximity network scenario that is 
used as illustrative example. Section [3] formalizes the notion of CeFM. Its decomposition into a set 
of CMs is described in Section [4] Section [5] formalizes a distributed coordination algorithm, which 
describes the coordination logic that a CD has to perform by relying on its CM. We prove correctness of 
the distributed coordination algorithm in Section [6] To this extent, in Section [6j we also formalize the 
notion of undesired interactions. Section |7] discusses related works. Conclusions and final remarks are 
given in Section [8] 

2 The distributed social proximity network scenario 

With reference to Figure [2| choreography diagrams use rounded-corner boxes to denote choreography 
tasks (e.g., getUserPref). Each of them is labeled with the roles of the two participants involved 
in the task, and the name of the service operation performed by the initiating participant and provided 
by the other one. A role contained in a white box denotes the initiating participant (e.g., IM); a role 
contained in a filled box denotes the receiving participant (e.g., UMS). 

The choreography in the figure models a small portion of a Distributed Social Proximity Network sce- 
naricj^J which concerns the collaboration of location-based services and citizen mobile apps. The chore¬ 
ography considers user preferences, user friend lists, and user location under predefined private data 
policy, to create ad-hoc itineraries between two citizens that know each other and are willing to meet 
in some place. In brief, upon receiving a start event from a citizen (i.e., from the dedicated mobile app 
named SocialProxApp), the Itinerary Manager (IM) calls the User Manager Service (UMS) to check 
if location sharing is enabled according to the citizen preferences. If yes (see the conditional branching 

5 Within CHOReOS, the scenario is part of a Dynamic Route system, which has been the pilot use case that we used to 
validate the overall choreography synthesis process. 
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Figure 2: BPMN2 choreography diagram of the Distributed Social Proximity Network scenario 


represented as a rhombus marked with a “x”), IM starts matching the GPS position of all citizen con¬ 
tacts by using the Social Proximity Service (SPS). Then, after interacting with UMS to get the list of all 
friends found nearby with location sharing enabled, SPS interacts with the SocialProxApps of the 
friends in the list to get their location. Finally, after a friend has been selected by the requesting citizen 
among the displayed list of available contacts, and the friend has accepted, SPS notifies in parallel the 
Notification Managers, NMU and NMF, for both the requesting user and the selected friend, respectively 
(see the parallel branch represented as an rhombus marked with a “+” with two outgoing arrows). These 
parallel flows are joined afterwards as soon as both the notification tasks have been accomplished (see 
the merging branch represented as an rhombus marked with a “+” with two incoming arrows), hence 
letting the two friends start their itineraries. An important aspect of this simple scenario is that the chore¬ 
ography in Figure [2] specifies that SPS must notify both the user and the friend before allowing them to 
start their respective itineraries. The choreography uses the merging branch at the right-hand side of the 
figure to model this desired behavior. When enforcing this choreography specification by using existing 
third-party services as participants, possible undesired interactions violating the specification can occur. 
For instance, the service playing the role of SPS attempts at notifying the user and starting his itinerary 
before notifying the friend. 



Figure 3: CeFM derived from the BPMN2 choreography diagram in Figure [2] 

Figure [3] shows the CeFM automatically derived out of the diagram in Figure [2] The numbering of the 
states in the CeFM depends on the performed model-based transformation. The symbol “-T denotes the 
classical negation in propositional logic. Transitions are possibly labeled by the initiating participant, the 
performed task, and the receiving participant, separated by ‘. 

In the following two sections, we formalize the notion of CeFM and its decomposition into a set of 
CMs, respectively. 


3 Choreography explicit-Flow Model 

Let ,T be the universal set of choreography tasks (e.g., service operations). Let M be the universal set 
of choreography roles. Let <I> be the universal set of Propositional Logic (PL) formulae. PL formulae 
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are used to distinguish choreography flows depending on whether a specific condition, represented as a 
predicate in PL, holds or not. More technically, according to the BPMN2 standard specification, in our 
implementation, a predicate is a conditional expression given in the syntax of the Java language. Thus, 
all data values involved in a predicate evaluation are assumed to actually range over finite domains. 

The following definition characterizes the structural properties of a CeFM as required for enabling 
automated synthesis of CDs. As already introduced in Section [T] the intuition behind Definition [T] is 
that a BPMN2 choreography diagram has to be transformed into an equivalent choreography model that, 
within the CDs synthesis process, allows to statically infer coordination-related information. 


Definition 1 (Choreography explicit-Flow Model) A Choreography explicit-Flow Model (CeFM) C is 

a tuple (S^ lt ,S poop ,S pork ,S j c oin ,S plain ,s 0 c / c ,Rc,Tc,D c ), where S^ LT ,S P00P ,S PORK ,S J ° IN and S PLAIN 

are disjoint and finite sets of states denoting alternative, loop, fork, join, and plain states, respectively, sji 

and s'c denote the initial (i.e., with no incoming transitions) and final (i.e., with no outgoing transitions) 

states, respectively, and they are neither alternative, loop, fork, join, nor plain states. Let Sc be the 

union set of all kinds of state, i.e., Sc=S^ LT US^ OOP US PORK US J c OIN US PLAIN U{s^,s{ : }. Rc is a finite set 

of roles, i.e., Rcff&. 7) C (ff% x -7 xM )U4> is a set of task labels called the alphabet of C. D( Q 

Sc X TcU {e} X Sc is the flow relation. £ denotes an £-task (i.e., an “empty” task). C is finite if Dc 

oc 

is finite and C is empty if Dc is empty. We will make use of the following notations: (i) g—>cf l iff 
(, g,Ot,h ) <G Dc A a=r.t ./ for some r.r'xR ( , t £ fT; (ii) g -—>ch iff (g.p.h) e Dc for some p£<t>; and 
(Hi) g—>cb iff(gi £ Ji) A Dc- In all the cases we will write that g is a predecessor ofh or, equivalently, 
h is a successor of g. The following structural properties hold: 


• plain: for all s plam £S PLAIN , s plam has only one predecessor .vG.SV\{.v^} such that s — > c s pla "‘ and 
s P lam has only one successor ^ / £S'c\{^} such that s p!am — y^s'; 

• alternative: for all s alt <LS kkT . s alt has only one predecessor .vG.SV;\{.v^} such that s — >cs al ‘ and 

s a,t has at least two successors si,.S2£S , c\{ 5 c} suc h that s alt -^Ac s l and s alt -^P- c s 2 f or some 
Pi-PiLW: for all pairs of successors (sfs'j), with i / j, and respective predicates Pi,Pjf_<P such 

that s alt -^c s ’i and s aR —-^cs’j then there is no variable assignment that makes PiFpj hold; 

• loop: for all s ,oop £S POOP , s loop has only two predecessors .v,.v / G.SV’\{.v^} such that s—^ c s loop and 

s' — >cs ,oop < and s loop has only two successors q,q'^Sc\{sc} such that s ,oop — >cq, s loop -^cd' 
for some p£<t>, and s' is reachable from q'; we call q' and q the loop entry state and exit state, 
respectively; 

• fork: for all sf ork £S PORK , s^ ork has only one predecessor .vG.S’c\{v^} such that s — >c s ^° rk ar, d 

s fork has at least two successors such that sf° rk — >c s ' and sf ork — >c s "; 

• join: for all s-' om GS{P IN , s ]0ln has only one successor 1 vG.SV'\{.Vf ; } such that s ' ,om — >c s and s p ’"‘ 
has at least two predecessors s',s”^Sc\{s^} such that s' — >c sk ° m and s" — >c s ^ om . 


BPMN2 specification employs the theoretical concept of token that, traversing the sequence flows and 
passing through the elements in a BPMN2 process, aids to define its behavior. In line with this concept, 
the formal semantics of a CeFM is given in Section [4] as a set of coordination models (see Definition [3]) 
obtained through the automatic generation process formalized by Definition [4] In particular, the gener¬ 
ation process leverages the notion of structural sequential flow in Definition [2] to formally model all the 
paths traversing the choreography diagram. The coordination models are meant to coordinate these paths 
according to the different state types. 
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Intuitively, the initial state of a CeFM generates the token that must eventually be consumed at the 
final state. If a token is on a plain state, then the outgoing flow is ready to be executed hence performing 
the operation characterized by its task label. If a token is on an alternative state, then one of the outgoing 
flows whose predicate holds is ready to be executed. This means that, according to the above structural 
properties, we deal with BPMN2 Diverging (Decision) Exclusive Gateways through alternative states 
whose outgoing flows are guarded by mutually exclusive predicates, i.e., at run time only one predicate 
evaluates to tru^] At the same time, according to the BPMN2 standard specification, we disallow the 
specification of non deterministic gateways with no condition specified. If a token is on a loop state, 
then the outgoing flow leading to the loop entry state is ready to be executed if its guarding predicate 
holds. Otherwise, the flow leading to the exit state will be performed. If a token is on a fork state, 
then all outgoing flows are taken simultaneously leading to several parallel executions, each having its 
own token. If, for each of its incoming flows, there is a token on a join state, then the outgoing flow is 
triggered. 

Due to the introduction of e-tasks, in general, a CeFM is non-deterministic. e-tasks are introduced 
for dealing with non-plain states both structurally and semantically. For instance, they can be used to 
specify cascading fork states or to model the (internal) event of creating parallel flows, which originate 
from a fork state. 

By leveraging the concept of token, alternative models, such as free-choice Petri nets m, might 
have been adopted. However, the deep study we have initially conducted within CHOReOS to precisely 
define, at the project level, the integration architecture for the CHOReOS Integrated Development and 
Run-time Environment (IDRE), led the whole consortium to agree on the definition of the CeFM model, 
which best met the (both formal and technical) requirements of all the software tools now integrated by 
the IDRE. Indeed, to the purposes of defining an integrated suite of tools to support the whole chore¬ 
ography life cycle, the CeFM model brings together many features of already existing formalisms and 
notations in the literature, and filters out those ones not strictly needed. Last but not least, one of the 
main requirements was to have a notation as close as possible to the BPMN2 choreography diagrams, 
while enabling formal reasoning and fully automatic treatment by all the IDRE components. 

4 Automated decomposition of a CeFM into a set of CMs 

From hereon let C=(S^ LT ,S^ OOP ,S PORK ,S J c OIN ,S PLAIN ,s^^ c ,Rc,Tcfic) be a CeFM. The ability of ex¬ 
plicitly identifying specific structural sequential flows of C represents a basic ingredient to support the 
automated synthesis of the CDs that cooperatively realize C. For instance, in order to deal with the syn¬ 
chronization of several parallel flows in correspondence of a join state, it is sufficient for a CD to extract 
out of C each of these flows as originating from the same fork. This allows a CD, reaching a join state, 
to be aware of (i) those CDs that must be notified about the reach of the join state and, complementary, 
(ii) those states (predecessors of the join state) that must be waited for. 

Definition 2 (Structural sequential flow) The sequence t=cx-, v \CXj . 2 - • is a structural sequential flow 
of C iff there exists a sequence of states .v ;.. ,s n G.S'c such that Sj ( —fc s i i • ■ ..v„_ i -~As n , i > 0, n > i. The 

... (x 

empty flow is denoted by £. We will make use of the following notation: .s i =>c Sn iff there exists n > 2 
such that si 2 —>c- • •— >c s n- 

As introduced in Section [TJ a further basic ingredient of our synthesis method concerns the distribution 
step for C. That is, C is distributed into a set of CMs, one for each CD. We recall that CDs are not 


6 Indeed, in our implementation we also allow the specification of default a branch, not considered here for simplicity. 

7 http://www.choreos.eu/bin/view/Documentation/WebHome 
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always generated for each pair of participants. Indeed, for two given participants, a CD is generated only 
when there is a dependency relation between them. This means that we do not require to always keep the 
global state of the choreography to enforce it. This characterizes the distributed nature of our synthesis 
approach. 

Each CM represents a local view of C. It is local since it models the coordination logic that has to be 
enforced on the interaction between two participants, p,- and pj. This is done by exchanging coordination 
information among the CD supervising p, and the CDs it needs to synchronize with. Thus, the set of all 
CMs can be considered as a distributed model of C. A CM characterizes the coordination information that 
is needed to automatically synthesize the coordination logic that the corresponding CD has to perform, 
while interacting with the other CDs, in order to realize C. 


Definition 3 (Coordination Model) Let i,jG N, with i f j, be the identifiers of two participant services. 
Then, the Coordination Model CM, j for the operations required by the participant i and provided by the 
participant j is the sel^of tuples {t | T € Sc x Tc x Sc x 2 NxN x$x 2 ScxNxN x 2 ScxNxN }. For each 
tuple {s,t,s',CD s i ,p ,Notify s ,Wait siblings{s) ) : 

• x denotes the CeFM source state from which the related CD can either perform the operation t 
or take a move without performing any operation {i.e., the CD can step over an e-task). In both 
cases, s' denotes the reached target state; 

• CD s i contains the set of (identifiers of) those CDs whose supervised services became active in s', 
i.e., the ones that will be allowed to require/provide some operation from s'. This information is 
used by the “currently active” CDs to inform the set of “to be activated” CDs (in the target state) 
about the changing global state; 

• p is a PL predicate whose validity has to be checked to select the correct tuple, and hence the 
correct flow(s) in the CeFM; 

• Notify s contains the predecessor of a join state that a CD, when reaching it, must notify to the 
other CDs in the parallel flow(s) of the same originating fork. Complementary, Wait sibtings ^ con¬ 
tains the predecessors of join states that must be waited for. 

According to the above definition, each CMjj is automatically synthesized out of C as formalized by the 
following definition. 


Definition 4 (Coordination Model Generation) Let I ..... /; be identifiers for n participant services 
playing the roles r n G A?, respectively. Then, CM j ; is generated out of C as follows: 

CM iJ={ {s,t,s',CD s i f rue,Notify s ,Wait\ s^4 c s'} U 


n.t.rj 


{{s,e,s',CD s /, true,Notify,,Wait sibUngs w ) \3s prec , t : s prec => c s —} U 
{ (s,e,s',CD s , ,p s . s :,Notify s ,Wait sihlings(s) )\ 3s prec , t : s prec '^=U c s^cs'} 


where 


CD s j= {(h,k)\(h,k)yI(i,j)N3s",t\ s''^ c s" } U 

{(h,k)\(h,k)^(i,j)F3p^,s",s succ ,f .} U 


{(h,k)\(h,k)^(i, j)Fs'FS F c 0RK CS J c 0IN N3s",s succ ,t: s' — > c s" rt! ^s mcc } 
Notify s ={[s, (h,k)}\s'eS J c 0fN A3s"fis,s prec ,t :s precr ^ c s"^cs'} 
Wait siblings ^= {[/', (h,k)]\s'eS J c P !N A3s"fs,s prec ,t ■. s prec '^=> k c s" —>ca'} 


M. Audli & M. Tivoli 


25 


CMimjjms 

CMsps.ums 

(55, getUserPre /(),56, {}, true, {},{}) 

(56,£,57,{},rrwe, {}, {}) 

(57,£,520, {}. —shareEnabled. {},{}) 

(57, £, 59, {( IM.SPS )}, shareEnabled , {},{}) 

(520, e, Final, {}, true, {},{}) 

(510, get Friends (), 52, { }, t rue ,{},{}) 

(52, £,58, {},true, {},{}) 

(58, e, 519, {}, -i friend Found, {},{}) 

(58, e,53.{ (SPS.SocialProxApp)}, friendFound. {},{}) 
(519, e,Final,{},true, {},{}) 

CM IMiSPS 

CMsps,SocialProxApp 

{S9,matchGPSQ,S10,{(SPS,UMS)},true,{},{}) 

( S3,getLocationsQ,S4 , {},true, {},{}) 

(54, £,513, {}, true, {},{}) 

(513, £, 511,{(SPS, NMF)}, true, {},{}) 

(513,£,514, {(SPS,NMU)},true, {},{}) 

CM SPSiNMU 

CMsps.nmf 

(514, notifyUser(),S15,{},true, {},{}) 

(515, £, 516, {}, true, {[515, (SPS,NMF)]}, 
{{S\2,{SPS,NMF)\}) 

(516, £, 521, {{SPS,NMF)}, true, {},{}) 
{S22,startItin(),S23,{},true, {},{}) 

(523, e,Final, {}, true, {},{}) 

(51 l,notifyFriend(),S12, {} Anie. {}.{[) 

(512, £, 516, {}, true, {[512, (SPS,NMU)]}, 

{[515, (SPS,NMU)]}) 

(516, £,521, {}, true, {},{}) 

(521, st art It in, 522, { (SPS, NMU ) },£rwe, {},{}) 


Table 1: Coordination Models Tuples 


Going back to our illustrative example, Table [T] reports the CMs derived from the CeFM in Figure [3] 
Intuitively, the first tuple in CM/m.ums specifies that CDjm,ums can perform the operation getUserPref 
from the source state S5 to the target state S 6; whereas, the second tuple specifies that CDjm.ums can 
step over S6 and reach SI, from where alternative branches can be undertaken. Then, as specified by the 
third and fourth tuple, CDjm.ums can reach either S20 or 59 according to the evaluation of the related 
conditions, i.e., -^shareEnabled or shareEnabled, respectively. This means that, after getU serPref has 
been requested by 1M and forwarded to UMS, in the case shareEnabled holds, CDjm,ums uses the fourth 
tuple (57, £,59, {(IM,SPS)},shareEnabled, {},{}} to step over the alternative state 57, reach 59, and 
inform CDim.sps about the new global state 59. 

Considering the second tuple (515,£,516,{},frw<?,{[515, (5P5,IVMF)]},{[512, (SPS,NMF)]}) 
in CMsps,nmUi CDsps,nmu notifies 515 to CDsps,nmf and waits for receiving the 
notification by CD$ps,nmf about 512. On the other hand, considering the tuple 
(S12,e,S16,{},true,{[S12, (SPS,NMU)]},{[S15, (SPS,NMU)]}) in CM SPS}NM f, CD sps ,nmf notifies 
512 to CDsps,nmu and waits for receiving the notification by CDsps,nmu about 515. Note that the same 
considerations apply in case different parallel threads of the same CD are involved in a join state. 

5 Choreography enforcement via distributed coordination 

In this section we formalize the distributed coordination algorithm that describes the coordination logic 
that each CD has to perform by relying on its CM. The algorithm inherits the distributed mutual exclusion 
principle and leverages some foundational notions (such as happened-before relation, partial ordering, 
and time-stamps) of the algorithm in f29ll . More precisely, the enforcement of mutual exclusive access to 
a single resource in |f29l is scaled up to the enforcement of concurrent task flows according to arbitrarily 
complex choreographies. In the style of ll29ll . the most appropriate way to present the algorithm is to 
define rules that each delegate CD, j follows in a distributed setting, when its supervised service 5, sends 
a request to perform a task t with Sj (without relying on any central synchronizing entity or shared 
memory). The actions defined by each rule are assumed to form a single event (i.e., each rule is atomic). 
As detailed below, a CD is a reactive entity that, at each iteration of the algorithm, WAITs for receiving 
either a request from the service it supervise or NOTIFY/UPDATE messages from the other CDs. 

s As usual, let 5 be a set, 2 s denotes the power-set of S 
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The rules locally characterize the collaborative behavior of the CDs at run-time from a clear one- 
to-many point of view. The most important aspect here is that, upon reaching a join state, the involved 
CDs notify and wait for each other in order to synchronize their execution. At run time, NOTIFY 
messages (together with a simple notion of priority Pjj, initially associated to each CD (/ ) are used 
to realize join states as distributed synchronization points. Then, when a join state has been realized, 
and hence all the parallel executions have been synchronized, the CD with highest priority is in charge 
of notifying the CDs that, according to the choreography, arc allowed to proceed. Each CD, j sends 
NOTIFY messages according to the coordination information contained by the sixth element of the CM,-j 
tuples. The “co-related” WAIT primitive is instead performed according to the information contained in 
the seventh element of the tuples. In our implementation, the correct co-relation among WAIT primitives 
and NOTIFY (or UPDATE) messages is realized by means of dedicated queues that, for each WAIT, 
buffer the expected NOTIFYs (or UPDATEs). CD i; uses UPDATE messages whenever the current 
global state of C changes according to the performed coordination. By considering the coordination 
information represented by the fourth element of its tuples, CD,j sends an UPDATE message in order 
to inform, about the state change, those CDs whose execution can progress from the new current global 
state. Thus, if a CD/,^ receives a request to perform a task t while its local execution is in a state where t 
is not allowed, then it waits for receiving an UPDATE message on a state from which t is allowed. 

In Table [2} we defined three rules. In brief, Rule 1 governs the exchange of business-level messages 
by considering the cases in which: a CD receives a message that is allowed by C, hence forwarding it 
to the interested service as soon as the CD reaches the enabling state of C; and a CD steps over £-tasks 
by exploiting the procedure defined in Table [3] Leveraging the distribution step of Definition [4] (which is 
performed statically), the procedure is capable to handle in a uniform way all kinds of states, i.e., plain, 
fork, join, alternative, and loop states. At coordination-level, Rule 2 and Rule 3 regulate the exchange 
of the UPDATE and NOTIFY messages, respectively. Specifically, Rule 2 updates the local current state 
of the CD according to the current global state of C as received through the UPDATE message. Rule 
3 allows the CD to proceed only after all the needed NOTIFY messages have been received. For the 
sake of presentation, the algorithm assumes that each alternative branch has at least one (and only one) 
enabling condition that evaluates to true. Furthermore, each participant does not request to perform a 
task that is not present in the choreography specification. However, our implementation of the algorithm 
is able to detect these cases raising specific exceptions. 

Adhering to Definition[4] the algorithm takes as input CMjj. Thus, let r be a tuple in CM if. 

• r Arc] (resp., rftrgj) is the enabling source (resp., target) state of the transition labeled with 
rfallowedOp]; 

• r AllowedOp] is the operation that can be performed by 5,- when in the source state; 

• TfallowedService] is the set of CDs (and hence, of supervised services) that can proceed from 
the target state; 

• rfcond] is the PL predicate associated to an alternative path, which allows a CD to proceed on that 
path whenever it holds; 

• TftoBeNotif ied] (resp., r[toBeWaited]) is the set of CDs that, progressing on parallel paths 
together with CD, j, must be notified (resp., waited for) as soon as CD (/ reaches the state joining 
the paths. 

At the beginning, all CDs are waiting for receiving an initiating UPDATE message to internally set the 
state(s) from which they can perform an operation. These messages are sent by an activating compo- 


M. Audli & M. Tivoli 


27 


nent, specifically developed within CHOReOS, called Enactment Engine (https : //github . com/ 
choreos/enactment_engine). The latter is also in charge of automatically deploying the CDs. 


Rule 1: Upon receiving, in the current state s of C, a request from .S', to perform a task t with Sj, 

1.1 if there exists z G CM, j s.t. rjsrc] = s and T[allowedOp] = t (i.e., t is allowed from s) then 

1.1.1 CDj j forwards to Sj the message initiating t, and gives the control back to S, [^j 

1.1.2 CDj j updates s to r|trg|; 

1.1.3 for all (h,k) G T[allowedService], CDjj sends UPDATE(r[trg]) to CD^y 

1.1.4 StepOverO); 

else if r|src] A s for each z G CMj j s.t. T[allowedOp] = t (i.e., t is not allowed from s) then 

1.1.5 CDj j WAITs for receiving UPDATEfrfsrcj), hence temporarily blocking .S', |~^| 


Rule 2: When CDjj receives UPDATE!state) for some state that it was waiting for then 

2.1 CDj j updates s to state', 

2.2 if a task t is pending p] then goto Rule 1.1; 


Rule 3: When CDj j receives all NOTIFY( predecessor, CD^y join ) it was waiting foipjthen 

3.1 if CDj j has the highest priority (i.e., for all CD^y Pi,j>Ph.k) then 

3.1.1 CDj j updates s to join', 

3.1.2 let z G CMj j be s.t. r[src] = join', 

3.1.3 for all (h,k) G T[allowedService], CDjj sends UPDATE(r[trg]) to CD^y, 

3.2 if a task t is pending then goto Rule 1.1; 

Table 2: Rule-based description of the algorithm 


StepOver(v): 

while there exists z G CMjj s.t. r[src] = s and r[allowedOp] = z.e.z (i.e., it is possible to 
proceed from s only by an internal task) and there exists z' G CMj j s.t. E [src] = T[trg] and 
r'[cond] holds do 

S t epOve r ( z' [t r g]); 

for all [s, (h,k)\ G r[toBeNotif ied], CDjj sends NOTIFY(s, CD^y ^l/trg]) to CD^y 
for all [s",(h,k)) G r[toBeWaited], CDjj WAITs for receiving NOTIFY(s", CD^y 
r[trg]) from CDi,y hence temporarily blocking S, (see Rule 3); 
for all (h,k) G T^allowedService], CDjj sends UPDATE(T'[trg]) to CD^y 


Table 3: StepOver procedure 


9 Note that (;) the Service-CD interaction is synchronous; (h) the CD-CD interaction is either synchronous or asynchronous; 
(iii) the CD-CD exchange of coordination information is asynchronous. 

10 See Rule 2. In other words, CDj j is in a source state, say s', different from s and it is waiting for being notified for s' to 
become the new current state of C. Note that, since the service-to-CD interaction is synchronous, the task t is pending and 5/ is 
waiting for receiving the control back from CDjj. 

"That is, upon receiving a request to perform t, CDjj was waiting to receive UPDATE(ifafe). 

12 See Rule 1.2.4. 
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Figure 4: Architecture of the enforced Distributed Social Proximity Network scenario 

Going back to our illustrative example, Figure [4] shows the software architecture of the system that real¬ 
izes the choreography specified by the CeFM shown in Figure [3] This system is composed of the services 
that instantiate the choreography participant roles (e.g., IM, SPS), the automatically synthesized CDs 
(e.g., CD im ,sps, CDsps.ums) together with their CMs (e.g., CM im ,sps , CM sps .ums ), synchronous con¬ 
nectors enabling Service-CD interaction by exchanging business level messages (e.g., the getUserPref 
and notify User operations), and asynchronous connectors enabling CD-CD interaction by exchanging 
additional coordination messages (e.g., NOTIFY and UPDATE messages). The deployment information 
needed to realize the structure of the depicted architecture is automatically synthesized by exploiting the 
set of generated CMs. 

As introduced above, at the beginning, CD/m.sps is waiting for receiving an UPDATE on state 59 (of 
the CeFM); CD/m.ums is waiting for receiving an UPDATE on 55; CDsps.ums is waiting for receiving an 
UPDATE on 510; CDsps.sociaiPm.xApp is waiting for receiving an UPDATE on 53; CDsps,nmu is waiting 
for receiving an UPDATE on either 514 or 522; and CDsps.nmf is waiting for receiving an UPDATE on 
either 511 or 521. Again, this information is automatically synthesized out of the generated CMs. Once 
the synthesized CDs are deployed, by obeying the constraints of the architecture shown in Figure [4] 
the CHOReOS Enactment Engine sends UPDATE(55) to CD/m.ums- hence starting the execution of the 
choreography. 

To illustrate the execution of the distributed coordination algorithm at work on our example, Figure [5] 
shows a sequence diagram representing an excerpj^Jof the exchange of business- and coordination-level 
messages among the participants and their supervising CDs. As it is evident from the diagram, the 
collaboration of the synthesized CDs coordinates the interaction among the participant services in order 
to let them perform only the interactions specified by the CeFM, hence preventing, e.g., the undesired 
interaction mentioned in Section |2] We recall that this undesired interaction concerns the case in which 
a notified friend takes on the created itinerary when the other friend has not been notified yet. 

13 From the initial state to S21, and by assuming that both shareEnabled and frienclFound hold. 
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Figure 5: Messages exchange for the Distributed Social Proximity Network scenario 
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6 Correctness 

In this section, we give a rigorous characterization of undesired interactions, and prove that our enforce¬ 
ment method prevents them. 

For our distributed coordination algorithm to be correct, it should never happen that: 

(i) a CD accepts a request to perform a task that is not allowed in the current state; 

(ii) although the task is allowed, the current state (a) has been reached by an alternative state whose 

condition does not hold; (b) is a loop entry state but the guard of the loop does not hold; (c) is 
a loop exit state but the guard still holds; (d) is the successor of a join state but some parallel 
flows must still be completed; (e) leads to a predecessor of a join state where, after performing the 
requested task, each involved CD is waiting for the others. 

These considerations lead to the following definition that characterizes the way undesired interactions 
can be detected at run-time. That is, an undesired interaction occurs whenever an undesired operation, 
as defined by Definition [5| occurs. In the definition, we make use of the following notations. CMjj(s) 
denotes the set of tuples in CM\ j with s as first element. CM (s) \o p denotes the set of choreography 
operations (different from e) appearing as second element of tuples in CMj j(s) (i.e., all the operations 
allowed from s). CMjj(s) |'wait denotes the union of valid triples in Wait s n,u ngs ( s ) (i.e., all the predecessors 
of .s' that must be waited for at run-time). The predicate ~A totifyij holds if and only if CDjj has not 
received yet all NOTIFY messages that it is waiting for. 

Definition 5 (Undesired operation) Let CM l } be the CM generated for the delegate CDi j out of the 
CeFM. Let s&Sc be the current state reached by CDj ; during its execution. A choreography operation 
a=rj.t.rj (for some ly . rj A R(- and t£f?) is an undesired operation in s if and only if one of the following 
conditions hold: 

• undesired task: a^CMjj(s)\o P ; 

• undesired flow: a<LCMjj(s)\ q p A one of the following conditions hold: 

- invalid alternative: 3s alt eS J ^ LT ,p& 3> : s alt -^cs A ^p; 

- invalid loop: 3s loop eS' c 00P ,p A4>: s loop A —'P; 

- missed loop: 3s loop eS l p OOP ,pe<L>,s' : s loop — >c* A s loop -^cs' A p; 

- missed join: 3sj° m £S J c OIN : s J,nn —> c s A ~ Notifyij; 

- deadlocking join: 3s poin &S J C P !N ,s' : —>v /V "" A CD L] is in s' A ~Notifyij A 

V(s",h,k)eCMij(s ) \wait : CD h k is in s" A ^Notify h , k . 

Correctness proof (by contradiction) - Let us suppose that, at run-time, the collaboration of the synthe¬ 
sized CDs and the participants performs an undesired operation. By Definition [5] this means that either 
an undesired task or an undesired flow has been performed. By referring to the distributed coordination 
algorithm defined in Section [5] the undesired task condition contradicts Rule 1.1. Now, let us con¬ 
sider all the cases that characterize the undesired flow condition. The invalid alternative, invalid loop, 
missed loop, and missed join conditions contradict the execution of procedure StepOver; finally, the 
deadlock condition contradicts the combined execution of StepOver with Rule 3 and Rule 2. In any 
case, we deduce a contradiction and, hence, the correctness proof is given meaning that the interaction 
among the generated CDs and the participants prevents any kind of undesired interaction. 
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7 Related work 

The method formalized in this paper is related to a large number of other approaches that have been 
considered in the literature in the domains of service-oriented and component-based engineering, and 
controller synthesis and priority scheduling. We discuss here only the ones that are closer to the auto¬ 
mated choreography enforcement problem. 

Service-oriented and component-based engineering - There are many approaches aiming at compos¬ 
ing services by means of BPEL, WSCI, or WS-CDL choreographers lITOl fill [30l [3T1 l33l 37] (40) . The 
common idea underlying these approaches is to assume a high-level specification of the requirements 
that the choreography has to fulfil and a behavioural specification of the participants. From these two 
assumptions, by applying data and control-flow analysis, the BPEL, WSCI or WS-CDL description of 
a centralized choreographer is automatically derived so that it satisfies the specified requirements. In 
particular, in Boil , the authors propose an approach to derive service implementations from a choreogra¬ 
phy specification. In lf37l , the authors assume that some services are reused and propose an approach to 
exploit wrappers to make the reused services match the choreography. Most of the previous approaches 
concern orchestration, which is a form of composition different form choreography. The former focuses 
on centralized coordination, hence resulting in a monolithic composition. Instead, the latter is a means 
for composing services in a fully distributed way. 

Despite the fact that the works described in lf37l 1401 7’ 22j [8l focus on choreography, they consider 
the problem of checking choreography realizability. Note that it is a fundamentally different problem 
from the one considered in this paper. In fact, our approach is reuse-oriented and aims at restricting, 
by means of the synthesized CDs, the interaction behaviour of the discovered (third-party) services in 
order to realize the specified choreography. Differently, the approaches described in 11371 1401 j7, 22j jS) 
are focused on verifying whether the set of services, required to realize a given choreography, can be 
easily implemented by simply considering the role-based local views of the specified choreography. That 
is, this verification does not aim at synthesizing the coordination logic, which is needed whenever the 
collaboration among the participants leads to global interactions that violate the choreography behaviour. 

Similarly, later work in ifTTl [35] valuably advances the state-of-the-art results. Then, most closely 
to our work, in ll20l the authors presents a framework for verifying choreographies using model- and 
equivalence-checking techniques. The framework enables the verification of some analysis tasks, i.e., 
repairability, realizability, conformance, synchronizability, and control for enforcing realizability. In 
order to check in sequence the system synchronizability and realizability using equivalence checking, 
distributed controllers are generated through an iterative process presented in lf2T) . Counterexamples are 
exploited to refine the behaviour of the controllers by adding new synchronization messages until both 
synchronizability and realizability can be enforced. 

Works in the area of the synthesis of runtime monitors from automata are described in 1381 |39ll . 
Note that runtime monitoring is mostly focused on the detection of undesired behaviours, while runtime 
enforcement focuses on their prevention. 

In the context of Reo connectors, a number of related works are worth to be discussed. The works 
described in I27ll28l l2l discuss different approaches to extract coordination/choreography specifications 
from BPMN diagrams, UML state diagrams, and UML activity diagrams. Automated synthesis of co¬ 
ordination/choreography specifications from scenario-based specification is addressed in lf32l ITtt. The 
works described in 11251124 . 261 are more specific with respect to the problem of distributed enforcemen¬ 
t/implementation of choreographies. In particular, in If25l . the authors provide a systematic and rigorous 
way of constructing hybrid (i.e., partially-distributed) connector implementations for distributed orches- 
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trations. In If24l. the authors define a new product operator for Constraint Automata (CA) whose compu¬ 
tation at run-time requires only relatively simple distributed algorithms. The work in ll26ll describes an 
hybrid approach for the automatic code generation of orchestrations with Reo. The main focus of these 
works is on hybrid enforcement approaches. 

Controller synthesis and priority scheduling - The controller synthesis problem is conceptually similar 
to ours (yet technically different). That is, given a system specification and a property, synthesize a 
controller that, once put in parallel with the system, enforces the satisfaction of the property. In 0, 
the authors describe a compositional approach for efficiently constructing a centralized controller. Then, 
in 1151 , they describe how to decompose a monolithic controller into a network of Reo connectors. The 
former focuses on compositionality of the synthesis rather than on controller distribution, whereas the 
latter focuses on data-flow coordination. 

In |fT9l , the synthesis of a distributed controller is made decidable by model-checking knowledge 
properties and exploiting temporary synchronization. Similar concepts have been exploited also for 
monitoring global properties in distributed systems ifTSll . Model-checking knowledge properties for ad¬ 
dressing scheduling problems in distributed systems has been exploited also in (6]j. The work described 
in ll34ll shares the same idea of using additional interactions in order to synthesize “joint” knowledge of 
several concurrent and distributed entities. Our notions of CM and coordination information resemble 
their notions of knowledge and temporary synchronization, respectively. 

Priorities define precedence relations between component actions. Since priorities can be used to 
restrict the behaviour of a system in order to avoid undesired states, our work is related to priority 
scheduling. In lfl2ll . a priority synthesis algorithm is presented. It aims at synthesizing a system that is 
deadlock-free or satisfies some safety property. In |fT3l , the authors describe an algorithm to synthesize 
local sets of priorities hence addressing distribution of the control logic. Priority-based synthesis of 
distributed controllers has been addressed also in ||9) and, in the Web service orchestration setting, in lf36ll . 
These works have been either conceived in the context of the BIP framework, which is quite different 
from ours, or adopting its main concepts and operations. 

8 Conclusions and future work 

We have formalized a method for the distributed enforcement of service choreographies. It takes as input 
a choreography specification given in the form of an automata-based model, called CeFM, derived from 
a BPMN2 choreography diagram. This specification is automatically decomposed into a set of CMs that 
contain the information, local to each participant service, needed to coordinate the global interaction of 
all the participants from outside so to realize the specified choreography. Relying on the generated CMs, 
a distributed coordination algorithm has been defined with the aim of characterizing the coordination 
logic that has to be performed by additional software entities, called CDs. Once inteiposed among the 
participant services, CDs collaborate with each other to enforce the specified choreography. 

We have illustrated the applicability of our method by means of a distributed social proximity net¬ 
work scenario. We have proven correctness of the defined algorithm with respect to preventing those 
interactions that do not belong to the choreography specification. To this end, we have rigorously char¬ 
acterized the notion of undesired interaction. 

The formalized method is implemented as part of a model-based tool chain released under the 
FISSi initiative (http : //www. ow2 . org/view/Future_Internet ) to support the development 
of choreography-based systems in the CHOReOS EU project. The proposed method has been also 
applied to other real-world use cases in the Airport, and Marketing and Sale domains. Refer to the 
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CHOReOSy/i/ web site http://choreos.disim.univaq.it for documentation. The applica¬ 
tion to these use cases has shown that the method is viable and the overhead due to the exchange of 
synchronization information is negligible. Indeed, in the worst case, it is bound by the number of tasks 
times the number of participants. 

Beyond the modelling of message-based interaction, BPMN2 Choreography Diagrams provide con¬ 
structs for specifying events. As future work, we plan to extend our definitions of CeFM, and related 
CMs, to account for event-based coordination. As a consequence, the distributed coordination algorithm 
formalized in Section [5] must also be revised. As mentioned in Section |T] our distributed coordination 
algorithm is general in the sense that it is service-independent. As a further future work, we will leverage 
our preliminary results in 0 |23l to release the assumption that the participants already match the corre¬ 
sponding role specifications. This means that we have to define an extended version of CDs that are able 
to address both coordination and adaptation issues in a modular manner, hence still promoting separa¬ 
tion of concerns. Moreover, we plan to prove other notions of correctness beyond undesired interaction 
prevention, e.g., progress or permissiveness, and deadlock freedom beyond deadlocking joins. Last but 
not least, not all choreographies can be enforced by our method and, as further future work, we should 
formally characterize the conditions under which a choreography is enforceable by our method. 
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